Add dependency sources for cross-module inheritance - #363

I’m a little hesitant to add three more CLI options, since they will be difficult to remove once released.

More broadly, a configuration file might be a better fit for describing sources and their dependencies. It could also leave room to associate source paths with module names, which may help with qualified lookup in the future.

Thanks for the review. I agree, adding multiple parameters can lead to bloat; originally I just tried to match the existing shape. I've now simplified it to one, but if you'd like to go the configuration way, I'm happy to take a look, though I'll need some input.

Option 1 - CLI

The PR is cut down to only --dependency-sourcedirs. (The generate(…) parameters stayed to mirror sourceDirs:/sourceFiles:.)

Option 2 - Config

A --config <file> option, one file per mockolo run, describing the inputs, e.g.:

module: ModuleB
sourceDirs: [Sources/ModuleB]
dependencies:
  ModuleA:
    sourceDirs: [Sources/ModuleA]
  RIBs:
    sourceDirs: [.build/checkouts/RIBs/ios/RIBs]

• Paths are relative to the config file. Each entry uses sourceDirs or sourceFiles to match the existing vocabulary, and sources from all entries are combined.
• Dependency sources must be listed explicitly, including sources of indirectly inherited protocols. Nothing is discovered from imports or packages.
• Module names could support module-aware lookup later. For now, mockolo would still resolve types by name alone and ignore module names.
• I'd probably choose YAML, as it's the convention, but it would need Yams as a parser dependency. We could use JSON without any dependency, or go the Swift manifest route, like Package.swift: it would be type-checked, but it needs a Swift toolchain at run time and code to compile and evaluate it.

How did you imagine it?

• Would the config cover inputs only, or would all other options be ported into it over time?
• Did you mean one project-wide file describing all modules? I don't have a strong preference, but I'm still proposing one file per run.
• How would --config work together with -s/-f/-srcs? Error?

@sidepelican gentle ping when you have a couple of minutes. Happy to work on this.

@farkasseb
Sorry for the late reply, and thanks for putting these options together!

This seems like a good opportunity to try Option 2 with a config file.
How about JSON5 for the format? I’d prefer to avoid adding a YAML parser dependency, and Foundation’s JSON5 support seems like a simple and practical option.

For the config structure, I wonder if we could use a single list of paths for each module, containing both directories and individual files:

{
  module: "ModuleB",
  sources: [
    "Sources/ModuleB",
    "Generated/AdditionalProtocol.swift",
  ],
  destination: "Tests/ModuleBMocks.swift",
  dependencies: {
    ModuleA: [
      "Sources/ModuleA",
      "Shared/SomeProtocol.swift",
    ],
  },
}

Mockolo could determine whether each path is a directory or a file at runtime and collect all the sources.
Since the config itself contains the list of paths, I don’t think we need a separate file list option in the config.
Paths relative to the config file sound good to me.

Would the config cover inputs only, or would all other options be ported into it over time?

I think of the config as an alternative to CLI arguments, so I’d like it to support the --destination and, eventually, as many of the other options as practical. That said, I don’t think we need to add support for everything at once.

Did you mean one project-wide file describing all modules? I don't have a strong preference, but I'm still proposing one file per run.

One file per run is what I had in mind too. Each file would describe the context for a single mockolo invocation, so the number of invocations would stay the same.

How would --config work together with -s/-f/-srcs? Error?

The existing input options already have a precedence order: -s takes precedence over -f, which takes precedence over -srcs. I suggest that if any of these options is provided on the CLI, it replaces the config’s sources list.
For other options, I’d generally expect explicitly provided CLI arguments to take precedence over config values.